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Art Unit: 2124 

DETAILED ACTION 

1 . This action is in response to the RCE filed on 4/21/04. 

2. Claims 1, 7, 9, 1 1 and 12 have been amended. 

3. Claims 1-2, 4-7, 9, 1 1-12 and 14-20 are pending. 

4. Claims 1-2, 4-7, 9, 1 1-12 and 14-20 are rejected under 35 U.S.C 1 12, second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the 
subject matter which applicant regards as the invention. 

5. Claims 1-2, 4-7, 9, 1 1-12 and 14-20 are rejected under 35 U.S.C. 102(b) as being 
anticipated by Mason (U.S. 5,668,998). 

Response to Amendment 
Claim Rejections - 35 USC § 112 

6. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

7. Claims 1-2, 4-7, 9, 1 1-12 and 14-20 are rejected under 35 U.S.C. 1 12, second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the 
subject matter which applicant regards as the invention. 

Regarding claims 1, 7, 9, 11 and 12, the phrase "being placed on a boundary" 
renders the claims indefinite because it is unclear whether it is referring to any tangible 
computer element. Therefore, this phrase is interpreted as "provides an interface". 

Per claims 2, 4-6, and 14-20, these claims are rejected for dependency upon 
rejected base claim. 



Application/Control Number: 09/66 1,916 Page 3 

Art Unit: 2124 

Claim Rejections - 35 USC §102 

8. The following is a quotation of the appropriate paragraphs of 35 U.S. C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

9, Claims 1-2, 4-7, 9, 1 1-12 and 14-20 are rejected under 35 U.S.C. 102(b) as being 
anticipated by Mason (U.S. 5,668,998). 

Per Claim 1 (Amended, as best understood): 

The Mason patent discloses: 

- a method for constructing a service providing system using a framework for 
service providing system which provides a service for an object system ("A 

framework of service objects is provided which enables a programmer to easily develop 
application methods which provide DICOM services or other custom services. An 
object-oriented application interface is provided. The objects provide a map between 
DICOM standard service objects and a group of associated objects within a framework. 
The associated service objects work together to provide a DICOM service. The service 
objects comprise a method or a computer program which operates in conformance with 
the DICOM standard." in column 1, lines 10-19 and column 1, lines 66-67 to column 2, 
lines 1-2) 



Application/Control Number: 09/661 ,916 Page 4 

Art Unit: 2124 

- preparing a framework for service providing system, which includes a data 
holding part for holding data relating to an object system for which a service 
providing system constructed by said framework provides a service ( The present 
invention provides a framework of service interface objects which map onto a service 
described in the DICOM standard. Each service interface object, when instantiated, is 
uniquely associated with a user handler and a provider handler ... An implemented 
DICOM service, or set of objects which implement the DICOM service, is placed in the 
framework of objects. The DICOM service collection of objects is then available to an 
application programmer accessing the framework in implementing the same or a similar 
DICOM service." in column 2, lines 3-7 and column 7, lines 43-48; the DICOM service 
collection of objects is interpreted as a data holding part) 

- a user interface part for receiving instructions from a user and for presenting data 
to the user when the user employs the constructed service providing system, the user 
interface part provides an interface between a computer and the user ("Turning now 
to Fig. 2, in a example of an operational scenario, a DTServicelnterface object 1 1 
initiates a request. This is true for all service classes. The only difference between a 
verify request and one of the print requests is the particular subclass of the 
DTServicelnterface object that is chosen by the application developer. The outgoing 
message is called a "Request". . . . The incoming message is called a "Confirmation". . . . 
At this point in time, the confirmation has been received, so the transaction is considered 
complete. It is the responsibility of the DTServicelnterface object to look at the status 
that was returned. If the status was success, the DTServicelnterface object may be 
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cleaned up. If the status was not success, it is the responsibility of the application 
developer to determine how to recover from a bad status. Any of these actions could 
cause the application developer to need to create a subclass of the appropriate 
DTServicelnterface class." in column 7, lines 64-67 to column 8, lines 1-3; column 8, 
lines 56-67 to column 9, lines 1-18; for example, see Fig. 2, "API", on the SCU side; the 
user is employing the constructed objects that provides the service. Therefore, the user is 
employing the constructed service providing system.) 

- an object system interface part for exchanging data between the object system 
interface part and said object system in accordance with a predetermined protocol 

("In the present invention, DICOM standard services are implemented by objects or o 
methods which exist within a toolkit framework. In a preferred embodiment, the 
framework is divided into application subsystems and internal subsystems. . . . 
Application subsystems provide a framework of objects mapped to an abstract form of 
DICOM services. The application framework and associated mapping to DICOM 
services provides an application interface to the toolkit framework. The application 
interface simplifies creation of an application program which provides DICOM services 
and conforms to DICOM protocol." in column 7, lines 49-63; the application interface is 
interpreted as an object system interface part; see Fig. 3, item 25 
"DTSERVICEINTERFACE") 

- an integrated control part for controlling said data holding part, said user 
interface part and said object system interface part ("Handler objects (SCUs/SCPs) 
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enable an application to send and return calls to and from other applications ... A 
SCU/SCP (service user handler/service provider handler) pair exists for each DICOM 
user service. The SCU, service user handler initiates a DICOM message service request. 
The SCP, service provider handler responds to the service request." in column 2, lines 
43-50; Handler objects (SCUs/SCPs) are interpreted as an integrated control part for 
controlling the DICOM service collection of objects, API, and application interface, 
which are interpreted as data holding part, user interface part and object system interface 
part, respectively. The DICOM service collection of objects is not the handler objects 
(SCUs/SCPs). Each service object, when instantiated, is uniquely associated with a user 
handler and a provider handler, see column 2, lines 5-9. Handler objects (SCUs/SCPs) 
controls the DICOM service collection of objects that they are associated with, API, and 
application interface by providing communication between the DICOM service collection 
of objects, API, and application interface.) 

- preparing a plurality of classes on the basis of each of said data holding part, said 
user interface part, said object system interface part and said integrated control 
part of said framework for service providing system; associating said classes with 
each other; and defining a sequence carried out between the respective classes 
wherein said object system interface part of said framework for service providing 
system converts external data, which are exchanged between said object system 
interface part and said object system, into a format of intermediate data which is 
independent of said protocol, and said integrated control part of said framework for 
service providing system converts said intermediate data into a format of internal 
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data which is handled in said service providing system, said data holding part and 
user interface part of said framework for service providing system handling said 
internal data which have been converted by said integrated control part ("Each 
service is functionally distributed among atomic service units, each unit representing the 
smallest portion of a service provided by the present invention. Each atomic unit is 
represented by a base class, from which service objects are derived ... A base class for 
handler object is provided from which an application subclasses to generate handler 
objects. Sub-classing enables an application to customize the actions taken by a service 
interface object. . . . The outgoing message is called a "Request". The request is encoded 
12 into a DICOM message. This involves two processes. First, the message is 
formulated into the DICOM Toolkit's own internal representation which we call an 
element list. Each individual attribute that together will compromise the message is 
represented in this list. The elements in the list then each in ram, dumped into packets 
specified by the DICOM protocol. The elements themselves, each know how to format 
themselves correctly. These packets are transmitted across a network 13 (ethernet, fddi, 
etc.) to a DICOM service provider. The incoming packets are decoded 14 by the service 
provider 15, and an element list that is identical to the one that was transmitted is created 
by the provider. The incoming message is called an "Indication". The decoding process 
determines the message type. This information is used to route the message to the correct 
DTProviderHandler " in column 57-67 to column 3, lines 1-4; column 8, lines 2-22). 



Per Claim 2: 

The Mason patent discloses: 
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- wherein said integrated control part of said framework for service providing 
system controls data which are held in said data holding part, and connects said 
data holding part with said user interface part to provide various services for said 
object system on the basis of data which are given from said user or said object 
system (column 2, lines 43-50 and column 2, lines 64-67 to column 3, lines 1-15). 

Per Claim 4: 

The Mason patent discloses: 

- wherein said service providing system is a monitoring system for monitoring an 
external apparatus serving as said object system (column 1, lines 27-29 and column 2, 
lines 13-15). 

Per Claim 5: 

The Mason patent discloses: 

- wherein said service providing system is a control system for controlling a 
controlled apparatus serving as said object system (column 1, lines 27-29 and column 
2, lines 10-21). 



Per Claim 6: 

The Mason patent discloses: 
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- wherein said service providing system is an information system for exchanging 
information between the service providing system and an information system 
serving as said object system (column 2, lines 35-42). 

Per Claim 7 (Amended, as best understood): 

This is a system version of the claimed method discussed above (claims 1 and 2), 
wherein all claim limitations also have been addressed and/or covered in cited areas as set 
forth above. Thus, accordingly, this claim is also anticipated by Mason. 

Per Claim 9 (Amended, as best understood): 

This is a computer readable recording medium version of the claimed system 
discussed above, claim 7, wherein all claim limitations also have been addressed and/or 
covered in cited areas as set forth above. Thus, accordingly, this claim is also anticipated 
by Mason. 

Per Claim 11 (Amended, as best understood): 

This is another version of the claimed computer readable recording medium 
discussed above, claim 9, wherein all claim limitations also have been addressed and/or 
covered in cited areas as set forth above. Thus, accordingly, this claim is also anticipated 
by Mason. 

Per Claim 12 (Amended, as best understood): 
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This is a computer readable recording medium version of the claimed system 
discussed above, claim 7, wherein all claim limitations also have been addressed and/or 
covered in cited areas as set forth above. Thus, accordingly, this claim is also anticipated 
by Mason. 

Per Claim 14: 

The Mason patent discloses: 

- wherein each of said data holding part, said object system interface part and said 
integrated control part includes a class which is prepared for every kind of object 
system, and said user interface part includes a class which is prepared for every 
kind of screens for interface (column 2, lines 57-67 to column 3, lines 1-15). 

Per Claim 15: 

The Mason patent discloses: 

- wherein said class included in said data holding part is prepared for every kind of 
data, which are used in said object systems, in addition to the kind of said object 
systems (column 2, lines 57-61). 

Per Claim 16: 

The Mason patent discloses: 
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- wherein said class included in said integrated control part is prepared for every 
kind of services, which are provided for said object systems, in addition to the kind 
of said object systems (column 2, lines 64-67 to column 3, lines 1-4). 

Per Claim 17: 

The Mason patent discloses: 

- wherein said class included in said integrated control part includes an upper class, 
which is prepared for every kind of said object systems, and a lower class which is 
prepared for every kind of services which are provided for said object systems 
under said upper class (column 2, lines 64-67 to column 3, lines 1-4). 

Per Claim 18: 

The Mason patent discloses: 

- wherein a class included in said integrated control part controls a class included in 
said data holding part (column 2, lines 43-50 and column 2, lines 57-67 to column 3, 
lines 1-4) 

- a class included in said user interface part updates and refers to said class included 
in said data holding part; data, which are given from said user and said object 
system, are exchanged between said class included in said user interface part and 
said class included in said integrated control part; and data, which relate to a 
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service provided for said object system, are exchanged between said class included 
in said integrated control part and said class included in said object system interface 
part (column 3, lines 5-15). 



Per Claim 19; 

The Mason patent discloses: 



- wherein when service providing instructions for said object system are given to a 
class included in a user interface part, said class included in said user interface part 
reflects data, which relate to service providing instructions, in a class included in 
said data holding part, and gives a class included in said integrated control part 
notice of said service providing instructions (column 2, lines 35-50 and column 3, lines 
5-15) 



- said class included in said integrated control part acquires data of said class 
included in said data holding part, and transmits data of said class, which is 
included in said data holding part, to a class included in said object system interface 
part, said class included in said object system interface part adding data, which 
relate to a protocol, to data received from said integrated control part (column 2, 
lines 64-67 to column 3, lines 1-4). 



Per Claim 20: 



The Mason patent discloses: 
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- wherein when service provided results from said object system are given to a class 
included in an object system interface part, said class included in said object system 
interface part deletes data, which relate to a protocol, from data received from said 
object system (column 8, lines 14-22) 

- and gives a class, which is included in said integrated control part, notice of service 
provided results, said class included in said integrated control part reflecting data, 
which relate to service provided results, in a class included in said data holding part, 
and giving a class, which is included in said user interface, notice of service provided 
results, and said class included in said user interface part acquiring data, which 
relate to service provided results, from said class included in said data holding part 
(column 8, lines 34-67 to column 9, lines 1-18). 

Response to Arguments 

10. Applicant's arguments with respect to claims 1-2, 4-7, 9, 11-12 and 14-20 have 
been fully considered but they are not persuasive. 
In the remarks, the applicant argues that: 

a) In the Final Office Action dated October 22, 2003, the Examiner rejected Claims 
1-2, 4-7, 9, 1 1-12, and 14-20 under 35 U.S.C j 102(b) as being anticipated by U.S. Patent 
No. 5,668,998 ("Mason"). Claims 1, 7, 9, 1 1, and 12 have been amended to further define 
and clarify the invention, and Applicant respectfully submits that the amendment 
overcomes this rejection and adds no new matter. 
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Amended Claim 1 is patentably distinguishable over the cited ait in that it recites, 
for example, the user interface part being placed on a boundary between a computer and 
the user. Amended Claims 7, 9, 11, and 12 include similar recitations. 

In the Final Office Action, the Examiner states that the API in FIG. 2 of Mason 
discloses a user interface part for receiving instructions from a user and for presenting 
data to the user when the user employs the constructed service providing system, as 
recited in independent Claims 1, 7, 9, and 12. Furthermore, in the Advisory Action, the 
Examiner states that as previously pointed out in Paper No. 9, Mason teaches a user 
interface part for receiving instructions from a user and for presenting data to the user 
when the user employs the constructed service providing system (column 7, lines 64-67 
to column 8, lines 1-3, column 8, lines 56-67 to column 9, lines 1-18', for example, see 
Fig. 2, 'API", on the SCU side). In addition, the Examiner states that Mason's API on the 
SCU side is interpreted as the user interface part where the application developer chooses 
the DT Service Interface object to initiate a request via the API. Furthermore, according 
to the Examiner, the application developer in Mason receives the status/confirmation of 
the request. If the status was not a success in Mason, then the application developer, 
according to the Examiner, needs to recover from this status, for example, by creating a 
subclass of the appropriate DT Service Interface class. 

While FIG. 2 may disclose an API, nowhere in Mason does it disclose the API 
receiving and presenting data when the user employs the constructed service providing 
system. Rather, Mason's API is merely an interface through which an application 
programmer customizes individual objects in the framework or alters parameter values 
and object behavior when developing the framework. Mason's API does not receive 
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instructions from a user or present data to the user when the user employs the constructed 
service providing system. Accordingly, Mason's API toolkit framework does not disclose 
the user interface part, as recited in independent Claims 1, 7, 9, and 12, which receives 
instructions from a user and presents data to the user when the user employs the 
constructed service providing system. 

Examiner 's response: 

a) Examiner strongly disagrees with applicant's assertion that Mason fails to 
disclose the claimed limitations recited in claims 1 , 7, 9, 11 and 12. Mason clearly shows 
each and every limitation in claims 1, 7, 9, 11 and 12. As per amended claims 1, 7, 9, 11 
and 12, the limitation "the user interface part being placed on a boundary between a 
computer and the user" is interpreted as "the user interface part provides an interface 
between a computer and the user"; see the rejection above in paragraph 7 for rejection 
under 35 U.S.C. 1 12, second paragraph to claims 1-2, 4-7, 9, 1 1-12 and 14-20. 

Furthermore, Mason teaches a user interface part for receiving instructions from a 
user and for presenting data to the user when the user employs the constructed service 
providing system, the user interface part provides an interface between a computer and 
the user (column 7, lines 64-67 to column 8, lines 1-3; column 8, lines 56-67 to column 9, 
lines 1-18; for example, see Fig. 2, "API", on the SCU side; the user is employing the 
constructed objects that provides the service. Therefore, the user is employing the 
constructed service providing system.) 

In addition, see the rejection above in paragraph 9 for rejection to claims 1, 7, 9, 
11 and 12. 
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In the remarks, the applicant argues that: 

b) Furthermore, Mason's Fig. 2 merely discloses that the interface (e.g., the interface 
for encoding / decoding image data) used by the handler objects (SCP/SCU) may be 
defined as an Application Programmers Interface (API). This does not mean that Mason's 
API is an interface placed on a boundary between a computer node and an end user (e.g., 
a person who employs the computer node). Instead, Mason's API corresponds to an 
interface placed between a first computer node and a second computer node so that the 
first computer may communicate image data with the second computer node through the 
API. 

In contrast, however, the claimed user interface part, for example, may be placed 
on a boundary between a computer node and an end user (a person, for example, who 
employs the computer node). This means that the claimed user interface part may, for 
example, be an API for user-to-node, and may not be an API for node-to-node. 

Moreover, in Mason's Fig. 2, the term "User" in "Service Class User (SCUT" is 
merely used to contrast it with the term "Provider" in "Service Class Provider (SCP)." 
Namely, both the SCU and the SCP are computer nodes, one of which (e.g., the SCU) 
receives image data from the other computer node (e.g., the SCP), whereas the other of 
which (e.g., the SCP) sends image data to the one computer node (e.g., the SCU). In other 
words, the terms "User" and "Provider" merely represent the roles or behaviors of the 
computer nodes connected via a network, and they may not represent end users who 
employ the medical system constructed by the framework. In addition, the SCU is 
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incorporated into a middleware for communication, and may not exist inside an 
application, see Mason, col. 8, lines 56-67 and col. 9, lines 1-18.) 

In contrast, the claimed user, for example, may mean an end user who actually 
employs the service providing system constructed by the framework. Moreover, the 
claimed user interface part may, for example, receive instructions from an end user or 
may display the status of the object system. 

In summary, Mason's SCU merely decodes image data sent from the SCP and 
transmits a message to the SCU. Mason's SCU does not include a user interface that is 
placed on a boundary between a computer node and an end user. 

Furthermore, Mason's API toolkit framework merely comprises an interface 
through which an application programmer may select to create an application that 
provides a particular DICOM service. (See Mason, col 3, lines 16-21.) Mason's API 
toolkit framework has nothing to do with either the SCU (as an API for node-to-node) or 
the claimed user interface part (for example, an API for user-to-node). 

Examiner 's response: 

b) Examiner strongly disagrees with applicant's assertion that Mason fails to 
disclose the claimed limitations recited in claims 1, 7, 9, 11 and 12. Mason clearly shows 
each and every limitation in claims 1, 7, 9, 11 and 12. As per amended claims 1, 7, 9, 11 
and 12, the limitation "the user interface part being placed on a boundary between a 
computer and the user" is interpreted as "the user interface part provides an interface 
between a computer and the user"; see the rejection above in paragraph 7 for rejection 
under 35 U.S.C. 1 12, second paragraph to claims 1-2, 4-7, 9, 1 1-12 and 14-20. 
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In response to applicant's argument that the references fail to show certain 
features of applicant's invention, it is noted that the features upon which applicant relies 
(i.e., end user) are not recited in the rejected claim(s). Although the claims are 
interpreted in light of the specification, limitations from the specification are not read into 
the claims. See In re Van Geuns, 988 F.2d 1 181, 26 USPQ2d 1057 (Fed. Cir. 1993). 

In addition, see the rejection above in paragraph 9 for rejection to claims 1, 7, 9, 
11 and 12. 

In the remarks, the applicant argues that: 

c) In addition, the Examiner states in the Final Office Action that the handler object 
(SCP/SCU) of Mason discloses an integrated control pad for controlling said data holding 
part, said user interface pad and said object system interface pad, as recited in 
independent Claims 1, 7, 9, and 12, and for controlling said internal system means and 
said object system interface means, as recited in independent Claim 1 1 . Mason, however, 
merely discloses that the SCP/SCU ensures that messages and events are in appropriate 
DICOM standard format (See col 2, lines 41-43.) Mason further discloses that the 
SCP/SCU enables an application to send and return calls from other applications. (See 
col 2, lines 44-46.) Unlike the claimed integrated control part, Mason's SCP/SCU does 
not control anything, much less a data holding pad, a user interface pad, or an object 
system interface part, as recited in Claims 1, 7, 9, and 12, or an internal system means or 
an object system interface means, as recited in Claim 11. 

Furthermore, Mason's handler objects (SCP/ SCU) merely enable an application 
to send and return calls to and from other applications. (See col 2, lines 43-44.) This 
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means that Mason's handler objects (SCP/ SCU) are incorporated into a middleware for 
communication, and thus do not exist inside an application. 

Moreover, Mason's actual framework structure is completely different from the 
Examiner's assertions that the handler objects (SCP/SCU) are an integrated control part 
for controlling the DICOM service collection of objects. For example, although the 
Examiner asserts that the DICOM service collection of objects corresponds to the 
claimed holding part, the DICOM service collection of objects may simply correspond to 
the handler objects (SCP/SCU) that accomplish DICOM services. 

Also, although the Examiner asserts that the API corresponds to the claimed user 
interface part, Mason's API is merely an interface placed between one computer node and 
the other computer node, as described above. Accordingly, Mason's API has nothing to 
do with the claimed user interface pad, which may be placed on a boundary between a 
computer node and an end user. 

In addition, although the Examiner asserts that the application interface 
corresponds to the claimed object system interface part, the term "application interface" 
may merely be a general expression of "API." According to Mason's Fig. 2, there is no 
component called "application interface." 

In this regard, even if the DICOM service collection of objects, API, and 
application interface are interpreted as a data holding part, a user interface part, and an 
object system interface part, respectively, the claimed invention is completely different 
from Mason. For example, although the claimed invention, for example, may include that 
the user interface pad "utilizes" the data holding part, Mason does not disclose the API 
utilizing the DICOM service collection of objects. In addition, although the claimed 
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invention may include, for example, that the integrated control part and the object system 
interface part utilize each other, Mason does not disclose that the handler objects 
(SCP/SCU) and the application interface utilize each other. 

In short, Mason does not disclose the above referenced recitations of independent 
Claims 1, 7, 9, 11, and 12. Accordingly, independent Claims 1, 7, 9, 11, and 12 
patentably distinguish the present invention over the cited art, and Applicant respectfully 
requests withdrawal of the rejection of Claims 1, 7, 9, 1 1, and 12. 

Examiner 's response: 

c) Examiner strongly disagrees with applicant's assertion that Mason fails to 
disclose the claimed limitations recited in claims 1, 7, 9, 11 and 12. Mason clearly shows 
each and every limitation in claims 1, 7, 9, 11 and 12. 

Mason teaches an integrated control part for controlling said data holding part, 
said user interface part and said object system interface part (column 2, lines 43-50; 
Handler objects (SCUs/SCPs) are interpreted as an integrated control part for controlling 
the DICOM service collection of objects, API, and application interface, which are 
inteipreted as data holding part, user interface part and object system interface part, 
respectively. The DICOM service collection of objects is not the handler objects 
(SCUs/SCPs). Each service object, when instantiated, is uniquely associated with a user 
handler and a provider handler, see column 2, lines 5-9. Handler objects (SCUs/SCPs) 
controls the DICOM service collection of objects that they are associated with, API, and 
application interface by providing communication between the DICOM service collection 
of objects, API, and application interface.) 
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Furthermore, the Examiner has already addressed the applicant's argument 
regarding "user interface part, which may be placed on a boundary between a computer 
node and an end user" in the Examiner's Response (b) above. 

In addition, Mason teaches an object system interface part (column 7, lines 49-63; 
the application interface is interpreted as an object system interface part; see Fig. 3, item 
25 "DTSERVICEINTERFACE".) 

In response to applicant's argument that the references fail to show certain 
features of applicant's invention, it is noted that the features upon which applicant relies 
(i.e., utilizes) are not recited in the rejected claim(s). Although the claims are interpreted 
in light of the specification, limitations from the specification are not read into the claims. 
See In re Van Geuns, 988 F,2d 1 181, 26 USPQ2d 1057 (Fed. Cir. 1993). 

In addition, see the rejection above in paragraph 9 for rejection to claims 1, 7, 9, 
11 and 12. 

In the remarks, the applicant argues that: 

d) Dependent Claims 2, 4-6, and 14-20 are also allowable at least for the reasons 
above regarding independent Claims 1 and 1 2 and by virtue of their respective 
dependencies upon independent Claims 1 and 12. Accordingly, Applicant respectfully 
requests withdrawal of this rejection of dependent Claims 2, 4-6, and 14-20. 



Examiner 's response: 
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d) The Examiner has already addressed the applicant's arguments regarding 
independent claims 1, 7, 9, 11, and 12 in the Examiner's Responses (a)-(c) above. In 
addition, see the rejection above in paragraph 9 for rejection to claims 2, 4-6, and 14-20. 



Conclusion 

1 1 . Any inquiry concerning this communication from the examiner should be directed 
to Qamrun Nahar whose telephone number is (703) 305-7699. The examiner can 
normally be reached on Mondays through Thursdays from 9:00 AM to 6:30 PM. The 
examiner can also be reached on alternate Fridays. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kakali Chaki, can be reached on (703) 305-9662. The fax phone number for 
the organization where this application or processing is assigned is (703) 872-9306. 

Any inquiry of a general nature or relating to the status of this application or 
proceeding should be directed to the receptionist whose telephone number is (703) 305- 
3900. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. Status 
information for unpublished applications is available through Private PAIR only. For 
more information about the PAIR system, see http://pair-direct.uspto.gov. Should you 
have questions on access to the Private PAIR system, contact the Electronic Business 
Center (EBC) at 866-217-9197 (toll-free). 
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